1. Field of the Invention
This invention relates generally to the field for software design; and, more particularly, to a diagnostic tool for an application environment supporting portable, embedded, concurrent, and/or real-time applications.
2. Description of the Related Art
The term “application” is commonly used to refer to the objective or problem for which the software, or “application program”, is a solution. The form of the solution—the application program—is dependent, in part, on the configuration of the hardware on which the software is executed and, in part, on the other programs that may be executing in concert with the application program.
An application program is typically translated from an instruction set derived from one of several well-known programming languages to an instruction set closely reflecting the capabilities of processor executing the application program. This translation is accomplished by programs generally know as “compilers,” “assemblers” or “interpreters.” These programs translate the application program's original instructions to a set of instruction typically know as “machine code” for which there is a one-to-one correspondence between machine code instructions and the unitary operations the machine (or processor) is able to perform. Typically, machine code instructions are dependent on the machine's central processing unit (or CPU). The operation of these and similar programs are well known to those of ordinary skill in the art.
Application programs are frequently executed simultaneously with other application programs, sharing (and sometimes competing for) the resources of the host hardware.
Application programs must also frequently share the resources of the host hardware with “interrupts service routines” (ISR). These ISRs are typically short program segments that interrupt the normal program instruction sequence and execute, substantially immediately, in response to a hardware signal (an “interrupt”) to the CPU.
Application programs may be invoked by, or may invoke, the services of other sets of programs running on the host that are collectively know as an “operating system.” Operating system programs are typically responsible for controlling the allocation of the host's resources, including access to the host machine's data stores, central processing unit, and input/output devices. One aspect of controlling the allocation of a host's resources typically involves insuring that no two applications, ISRs, or portions of the same application try to control a resource at the same time. A number of techniques for preventing this are well know in the art, including semaphores, counting semaphores, mutexes, signals, and critical sections. A critical section is a portion of a program that, once started, is uninterruptible and executes continuously without allowing other programs to run until the critical section has ended.
Application software is executed within some “host environment,” defined collectively by the host machine's hardware (including, possibly, application-specific support hardware such as an application-specific integrated circuit or “ASIC”) and operating system.
Commonly, commercial application software vendors are required to adapt, or “port,” their application programs to run in a multiple heterogeneous host environments. These environments may differ in their CPU's, choice of operating systems, and applicaton-specific hardware. In order to port an application program from one host environment to another, it is typically necessary to account for any or all of these differences.
The tradition approach to porting applications is to write the application program in a “high-level language” that hopefully can be recompiled to generate machine code that can run within any of the prospective processors. While this “traditional approach” solves the portability problem at the machine code level, it is only partly addresses the application portability problem. It is also necessary to account for differences in the host environment's operating system and application-specific support hardware. For example, each operating system defines a unique application programming interface (“API”) which application programs use to access the operating systems services. Because these APIs are unique, portions of the application program having access to the operating system's API must be rewritten when the application program is ported to a new operating system. In addition, accounting differences in application-specific support hardware (circuits that are able to perform a portions of the application's function that otherwise have to be performed in software) also may require that some portion of the application software be rewritten.
A problem with the traditional porting method is that this method requires that at least some portion of the application program be rewritten. This is a potentially costly and error-prone process. Because there is a likelihood of introducing unintentional errors whenever the application program is altered, this method mandates that the application developer bare the additional expense of re-testing the application after the indicated changes are complete.
More significantly, and despite the availability of a number of commercially operating systems, most embedded applications are deployed today are in host environments that supply no operating system services. Thus, for application portability, a means must be provided to ensure application software can operate correctly isolated from the vagaries of its host environment.
Software developers traditionally desire tools for observing and controlling intermediate operations of their programs as an aid in demonstrating the correctness of their programs and for debugging.